When the enum option is enabled, each member's // comment is taken from x-enum-descriptions / x-enumDescriptions. The description is handed to addSyntheticLeadingComment as single-line comment trivia, so a value that contains a line break ends the // comment at the first newline and the remaining text is printed as code. The generated enum then fails to parse.

For example, an x-enum-descriptions entry of "Code 100\nspanning two lines" currently produces:

enum ErrorCode {
    // Code 100
spanning two lines
    Value100 = 100,
}

addJSDocComment already handles this for property descriptions by running them through LB_RE (and escaping */), but tsEnumMember was the one comment path that skipped it. This change collapses internal line breaks in the enum-member description with the same LB_RE, so it stays on the single // line:

enum ErrorCode {
    // Code 100 spanning two lines
    Value100 = 100,
}

Single-line descriptions are unaffected.

Verification: added a tsEnum unit test in test/lib/ts.test.ts. It fails on main (the second line lands outside the comment) and passes with this change; the remaining ts.test.ts cases and the enum transform tests still pass.